本文详细解析了 MySQL 的 SQL 执行流程、crash-safe 机制及性能优化策略。内容涵盖连接器、分析器、优化器、执行器与存储引擎的工作原理，深入探讨 redolog 与 binlog 的两阶段提交机制，并分析日志策略、组提交、脏页刷盘等关键性能优化手段，帮助提升数据库稳定性与执行效率。
配置文件中，max_connections 用于控制最大连接数，默认值151。
需要注意的是，连接操作比较耗资源，所以通常用长连接，不过长连接有内存占用的问题。解决方案定时断开或者在大查询之后断开重连（5.7之后可以调用 MySQL_reset_connection()，在不断开的情况下释放资源）
MySQL 的优化器不是很完美，有时候需要优化 SQL，需要用 explain 分析索引使用情况
实现方式：WAL（预写式日志） 技术，先写日志再把数据写磁盘，保证数据操作的原子性和持久性
InnoDB 存储引擎功能，记录的是物理日志，记录的是数据页的物理修改（指 InooDB 中同一数据页在磁盘上和内存中的差异，因为是顺序IO，性能会比随机IO快，这种数据页叫脏页）
如何保证归档的数据和当前的数据相同，也就是如果让 “当前数据” 与 “备份数据” 一致或主机与从机数据一致。
写日志执行过程为两阶段提交 prepare-commit ，保证了数据逻辑上的一致性
数据库的主要性能瓶颈就是磁盘IO，相对于内存来说，磁盘太慢了。要提高性能就需要减少刷盘次数。
后台有一个线程每秒写盘（write + fsync），刷盘的时候能顺带把其它未提交的事务数据刷新，有数据丢失的风险，最多丢失1秒的数据，但是IO性能会更好。
将某个脏页刷新到磁盘前，会先保证该脏页对应的 redolog 刷新到磁盘中
上面两阶段提交，必须要格外注意的是，redolog 刷盘时机是在两阶段中的 prepare，commit 其实不需要刷盘(重启后校验 binlog 完整性)
在 redolog 中有 LSN 日志逻辑序列号，记录 redolog 写入点，每次递增日志的写入长度。通过 LSN 能判断，在事务提交的时候可能其它事务已经帮你刷盘了，不需要重复刷盘。 让 redolog 的刷盘尽量靠后，可以越来越好的利用组提交。
binlog 也有组提交，不过一般用不上，因为 redolog 的 fsync 步骤比较快，达不到积累binlog日志的效果。
在 sync_binlog 设置为1时如果你想提升 binlog 组提交的效果，可以修改如下配置：
InnoDB 并没用操作系统中文件系统自带的缓存，而是自己实现缓存，InnoDB 中数据以页为单位从磁盘中加载到内存，页的大小一般为 16 KB，为减少磁盘 IO 负担，当内存数据页数据有修改时，并不会立即更新到磁盘中，而是等待特定的时机刷新。
记录内存数据页和磁盘数据页之间物理差异就是 redolog 的工作, 脏页的刷新和 redolog 息息相关。
刷脏页（这里指内存数据页与磁盘不一致，相反的叫干净页）的过程叫 flush，flush 时机有以下几种情况：
配置文件中，innodb_io_capacity 这个参数告诉 InnoDB 磁盘的性能，控制全力刷新磁盘时的性能，默认200
可以使用用 fio 测试磁盘的 IOPS，机械硬盘建议100，SSD 建议200或更高，比如1000，最高不建议超过20000
实际使用时，不可能让磁盘一直全力去刷新，所以要控制不同程度下动态处理使用不相同的速度百分比
配置文件中，innodb_flush_neighbors 表示如果脏页旁边也是脏页，是否一起flush，用于机械盘设置为1，用于 ssd 建议设置为0（MySQL8的默认值）
本实验从Web应用上云这个最基本的、最普遍的需求出发，帮助IT从业者们通过“阿里云Web应用上云解决方案”，了解一个企业级Web应用上云的常见架构，了解如何构建一个高可用、可扩展的企业级应用架构。
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 相关的阿里云产品：云数据库RDS MySQL 版 阿里云关系型数据库RDS（Relational Database Service）是一种稳定可靠、可弹性伸缩的在线数据库服务，提供容灾、备份、恢复、迁移等方面的全套解决方案，完全解决数据库运维的烦恼。 懂产品详情:
美团面试：MySQL有1000w数据，redis只存20w的数据，如何做 缓存 设计？
美团面试：MySQL有1000w数据，redis只存20w的数据，如何做 缓存 设计？
本文探讨了在MySQL中对百万级数据来进行排序分页查询的优化策略。面对五百万条数据，传统的浅分页和深分页查询效率较低，尤其深分页因偏移量大导致性能显著下降。通过为排序字段添加索引、使用联合索引、手动回表等方法，有效提升了查询速度。最终建议依据业务需求选择正真适合方案：浅分页可加单列索引，深分页推荐联合索引或子查询优化，同时结合前端传递最后一条数据ID的方式实现高效翻页。
在CentOS 8.x上安装Percona Xtrabackup工具备份MySQL数据步骤。
以上就是在CentOS8.x上通过Perconaxtabbackup工具对Mysql进行高效率、高可靠性、无锁定影响地实现在线快速全量及增加式数据库资料保存与恢复流程。通过以上流程可以有效地将Mysql有关的资料按需求完成定期或不定期地保存与灾难恢复需求。
在Linux环境下备份Docker中的MySQL数据并传输到其他服务器以实现数据级别的容灾
以上就是在Linux环境下备份Docker中的MySQL数据并传输到其他服务器以实现数据级别的容灾的步骤。这样的一个过程就像是一场接力赛，数据从MySQL数据库中接力棒一样传递到备份文件，再从备份文件传递到其他服务器，最后再传递回MySQL数据库。这样，即使在灾难发生时，我们也能够迅速恢复数据，保证业务的正常运行。
MySQL 提供了多种存储引擎，每种引擎都有其独特的特点和适用场景。以下是一些常见的 MySQL 存储引擎及其特点：
SpringBoot 通过集成 Flink CDC 来实时追踪 MySql 数据变动
通过详细的步骤和示例代码，您可以在 SpringBoot 项目中成功集成 Flink CDC，并实时追踪 MySQL 数据库的变动。
【YashanDB知识库】MySQL迁移至崖山char类型数据自动补空格问题
**简介**：在MySQL迁移到崖山环境时，若字段类型为char(2)，而应用存储的数据仅为0或1，查询时崖山会自动补空格。原因是mysql的sql_mode可能启用了PAD_CHAR_TO_FULL_LENGTH模式，导致保留CHAR类型尾随空格。解决办法是与应用确认数据需求，可将崖山环境中的char类型改为varchar类型以规避补空格问题，适用于所有版本。
【YashanDB知识库】字符集latin1的MySQL中文数据如何迁移到YashanDB
本文探讨了在使用YMP 23.2.1.3迁移MySQL Server字符集为latin1的中文数据至YashanDB时出现乱码的问题。问题根源在于MySQL latin1字符集存放的是实际utf8编码的数据，而YMP尚未支持此类场景。文章提供了两种解决办法：一是通过DBeaver直接迁移表数据；二是将MySQL表数据转换为Insert语句后手动插入YashanDB。同时指出，这两种方法适合单张表迁移，多表迁移可能存在兼容性问题，建议对问题表单独处理。
1. 先更新Mysql，再更新Redis，如果更新Redis失败，可能仍然不⼀致 2. 先删除Redis缓存数据，再更新Mysql，再次查询的时候在将数据添加到缓存中 这种⽅案能解决1 ⽅案的问题，但是在⾼并发下性能较低，⽽且仍然会出现数据不⼀致的问题，⽐如线删除了 Redis缓存数据，正在更新Mysql，此时另外⼀个查询再查询，那么就会把Mysql中⽼数据⼜查到 Redis中 1. 使用MQ异步同步, 保证数据的最终一致性 我们项目中会依据业务情况 , 使用不相同的方案来解决Redis和Mysql的一致性问题 : 1. 对于一些一致性要求不高的场景 , 不做处理例如 : 用户行为数据 ,
对百万级别数据来进行高效过滤查询，需要综合使用索引、查询优化、表分区、统计信息和视图等技术方法。通过合理的数据库设计和查询优化，可以明显提升查询性能，确保系统的高效稳定运行。
MySQL create table as与create table like对比
【紧急救援】MySQL CPU 100%！一套组合拳教你快速定位并解决！
【Docker】（3）学习Docker中 镜像与容器数据卷、映射关系！手把手带你安装 MySql主从同步 和 Redis三主三从集群！并且进行主从切换与扩容操作，还有分析 哈希分区 等知识点！
MySQL包安装 -- Debian系列（离线DEB包安装MySQL）